United States Patent [19] 

Fischer 



US005390247A 

[U] Patent Number: 
[45] Date of Patttte 



5,390,247 
Feb; 14, 1995 



[54] 

[76] 

[21] 
[22] 



METHOD AND APPARATUS FOR 
CREATING, SUPPORTING, AND USING 
TRAVELLING PROGRAMS 

Inventor. Addison M. Fischer, 60 14th Ave, 
South, Naples, Fla. 33942 

AppL No.: 123,676 

Hied: Sep* 20, 1993 



Related VS. Application Data 

[63] Continuation of Ser. No, 863,552, Apr. 6, 1992, aban- 
doned. 



[51] Int (X 6 — 

[52] us. a. _ 

[58] Field of Search . 



H04L9/00 

~. 380/2% 380/30 

380/23, 25, 4, 49, 30; 

395/200 



[56] 



References Cited 
U.S. PATENT DOCUMENTS 



4,868,877 
5,005,200 
5,040,142 
5,142,578 
5,164,988 
5,214,702 
5,261,002 
5,337,366 



1/1989 
4/1991 
8/1991 
8/1992 

11/1992 
5/1993 

11/1993 
8/1994 



Fischer 

Fischer 

Mori et at . 
Matyes et aL 
Matyes et aL . 
Fischer 



Perlman et al. . 
Fischer 



.380/25 
. 380/25 

380/30 
380/25 
, 380/25 
, 380/25 
.380/25 



OTHER PUBLICATIONS 

Office Automation Concepts and Tools, 1985, Sprin- 
ger-Verlag, Berlin, DE pp. 113-133, J. Hogg, "Intelli- 
gent Message Systems'*. 

The Computer Journal, vol 33, No. 4, Aug. 1990, Cam- 
bridge, GB, pp. 290-295, C Mitchell et aL, "A Secure 



Messaging Architecture Implementing The X.400-1988 
Security Features". 

Primary Examiner — Salvatore Cangialosi 
. Attorney, Agent, or Firm — Nixon & Vanderhye 

[57] ABSTRACT 

A method and apparatus for creating, supporting and 
using a •travelling program" is disclosed. A ''travelling 
program" is a digital data structure which includes a 
sequence of instructions and associated data and which 
has the capability of determining at least one next desti- 
nation or recipient for receiving the travelling program 
and for transnntting itself together with all relevant data 
determined by the program to the next recipient or 
des tinat i on . The travelling program can compute, ac- 
cording to any algorithm, the digital material which is 
to be signed, and also, as needed, the digital material 
which is to be verified. The program can conditionally 
decide, based on any known criteria, which users 
should participate in the signature process. Digital sig- 
natures allow the travelling program to provide other 
types of valuable authentication. The travelling pro- 
gram operates to automate data collection among a 
group of users. It can be sent to one user, attach, (or 
detach) relevant data files and move on to the next user. 
Data or files, collected from one or more users can be 
deposited with another user, or accumulated for 
batched processing as desired. This methodology elimi- 
nates the need for individual users to be counted on to 
transmit all the required data in the required format 
The present invention also efficiently performs elec- 
tronic data interchange (EDI) in the context of a travel- 
ling program which sends itself from user to to the next 
within an organization, collecting, editing and approv- 
ing data, 

: .:.r- 29 Claims, 29 Drawing Sheets 
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- table, the actual digital material which is signed is en- 

METHOD AND APPARATUS FOR CREATING, tirely different 
SUPPORTING, AND USING TRAVELLING It is anticipated that the type of digital signature de- 

FROGRAMS scribed above may be applied to data construction 

5 which will have a long Hfe — and perhaps be verified by 
This is a continuation of U.S. patent application Sen different entities over a period of time. In the case of 
No. 07/863,552, filed Apr. 6, 1992, now abandoned. EDI, for example, the signatures can be bound to the 

FIELD OF THE INVENTION EDI transaction itself* and may be verified by any fu- 

_ , ture recipients of that transaction, even outside the 

The present mvention relates to a method and appara- 10 context of the travelling program. This type of digital 
T ™?*T& a . ^veflmr program which has the signature is analogous to a hand-written signatare 

C? #? r 5^! mg together neCCSSai ? ^ which appears at the bottom of a paper purchaseorder 
ciated data from one computer user to another to or contract 

thereby cr^ a powerful ^ for processing, authentic ^ to ^ able to ^ ^ ^ 

eating, and collecting data at various computer nodes. 15 present mventi on also allows thelrograin^ condi^ 
BACKGROUND AND SUMMARY OF THE ^ decide, based on any known criteria, which users 
INVENTION should participate in the signature process. 

Within an organization, documents are often moved 2?" 

manually. A mail or delivery service is often employed 20 ^ program ^ ^ determmatl0ns ' 

when documents are required to be tramrnitted be- the Program, as to what couture requirement may 

tween organizations. ™?- for P arucnlar ™**> or some combination. 

Techniques for dectronicaUy transmitting documents "I^^nKJudemrWtnm contained in a user's X.500 

within an organization and between organizations are cer ™ cate » °f c ? hanccd certificate (eg., as ac- 

well known. The rapid growth of electronic mafl sys- 25 *> US * **■ Na 4 > 8 ^ 8 !l or 

terns, electronic transfer systems and the like have 5,005,200). Because complete programmatic flexfcflity 

served to automate certain business transactions and enst ?> 50011 extractcd information can even be used to 

eliminate some of the manual document transfers that . regulate ^ futaic tonsmission route for the travelling 

are in most instances unnecessary. program. 

One prior art methodology for automatically trans- 30 M f^tion to using digital signatures for simple au- 

ferring information between users (for example, within thenticaraon, the present mvention also allows authority 

an organization) utilizes a so-called "electronic forms" requirements and uses to be included and verified as 

methodology. This "electronic form" methodology wdL Til ^ s <kws upon, for example, the teachings of 

presents data to a user, solicits the user's input via a ***** ^ os - 4,868,877 and 5,005,200 to control au- 

conventional display, verifies mat the input data has 35 tkority proof and delegation. 

been correctly entered, and thereafter transmits such 011 nand » Present invention also allows 

data to another user. uses digital signatures to allow the travelling program 

The electronic form methodology is very limited in to Provide other types of valuable authentication. For 

many respects. For example, if the data represents any example, as a security convenience the present inven- 

value, then there is always the potential danger that 40 tion allows for the digital signature authentication of the 

data could be manipulated or altered, or simply created entire transmission from one user to another. This in- 

bogusly. Attempts to address this danger have involved eludes the travelling program itself, its variables, and 

flagging certain critical fields which are to be digitally any ancillary data or files. 

signed. This allows a certain limited amount of authenti- This second type of digital authentication differs 

cation for specific input fields, exactly as they were 45 f fom the data-oriented authentication described above, 

entered. hi part, in that it carries long-term significance — since 

However, it does not permit complex data structures the variables and other data winch are transmitted will 

to be assembled and then digitally signed. The present °e changed once the receiving user has taken any action 

invention allows for the travelling program to compute, aU* This second type of authentication is therefore 

according to any algorithm whatsoever, the digital 50 primarily seen as a protection against tampering, and 

material which is to be signed, and also, as needed, the C2n also be used forensicaHy as a backward audit to 

digital material which is to be verified. detect unauthorized tampering even by one of the ac- 

Thus, for example, the present invention allows the tual users of the form. . 

actual data which is signed to be different than any field In addition, the present invention also provides a, 

itselfrln fact, it is possible that the signed material 55 third type of authentication^ whereoy' the travelling 

contains none of the actual data as presented by the program itself may be signed, authenticated and autho- 

user. rized by some trusted issuing authority (eg., perhaps 

An example, of one way this is especially useful is the author), to insure that no bugs or "viruses" have 

when the travelling program of the present invention been introduced. (This even protects against infection 

creates an EDI (electronic data interchange) rransac- 60 by a user which has valid possession of the program 

tion based on aspects of the entered data. The program along the route). 

has the ability to sign the EDI transaction. Such EDI The present invention provides a unique mechanism 

transactions may well be composed of complex digital for Automating data collection among a group of users, 

information which was looked-up, based on internal The travelling program may be sent to one user, attach 

tables within the program, from other tabular files, or 65 (or detach) relevant data files and move on to the next 

from the supervisor or interpreter which drives the user. Data or files, collected from one or more users can 

travelling program. Thus, input fields which may have be deposited with another user, or g^wmilatfd for 

been simply entered as "X"s which selected from some batched processing as desired. This methodology elimi- 
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nates the need for individual users to be counted on to FIGS. 18 and 19 delineate the sequence of operations 

transmit all the required data in the required format performed for executing external functions or calls; 

The present invention also efficiently performs elec- FIGS. 20 and 21 delineate the operations which are 

tronic document interchange (EDI) in the context of a performed when a travelling program mails itself to a 

travelling program which sends itself from user to to 5 predetermined recipient; 

the next within an organization, collecting, editing and FIG. 22 dftlinpates the sequence of operations for 

approving data. At the appropriate point, as determined attaching a file to the travelling program; 
by the program's logic, it is then able to programmati- FIG. 23 shows how a file may be erased from a user's 

cally generate a standard EDI transaction (e.g., such as system; 

the X12 850 Purchase Order Transaction set) for trans- 10 FIG. 24 shows the sequence of operations performed 

mission to another organization. The travelling pro- in detaching a file from a travelling program; 
gram is able to digitally sign the finished transaction set FIG. 25 delineates the sequence of operations per- 

Accordingly, any receiving organization which can formed when a file has been transformed into a user file; 
process the standardized EDI, and the standardized FIG. 26 delineates the sequence of operation per- 

signature will be able to authenticate and process the 15 formed when material is to be digitally signed; 
mcoming material, even if the receiving organization FIG. 27 delineate the sequence of operation per- 

does not have all the powerful, techniques available formed by a "INTER-ROLLOUT" function; 
which are taught by the present invention. FIG. 28 shows the sequence of operations performed 

Conversely, the present invention allows a travelling when displaying information to the user; 
program to receive ordinary EDI transaction, possibly 20 FIG. 29 delineates the sequence of operation per- 

signed, and allows them to be parsed and incorporated formed by the "time delay" routine; 
into its variables. The travelling program then has the FIG. 30 shows the sequence of operations for a "se- 

capability of validating the input and incorporating lect from directory" function; 

them into displays, and to move them among various ^ FIG. 31 is a routine which demonstrates how the 

recipients as necessary. interpreter program permits a user to perform digital 

_ _ siEnaturesi 

BRIEF DESCRIPTION OF THE DRAWINGS ^q. J 2 exanj>mes ho W a ^ verifies received 

These as well as other features of this invention will information; 

be better appreciated by reading the following descrip- ^ FIG. 33 illustrates how a travelling program collects 

tion of the preferred embodiment of the present inven- a file to be transferred; 

tion taken in conjunction with the accompanying draw- FIG. 34 illustrates the travelling program operations 

ings of which: performed in reading data from a specified file; 

FIG. 1 is a block diagram of a communication system FIG. 35 illustrates how the travelling program may 

in accordance with an exemplary embodiment of the 35 update or create a file from program variables; 

present invention; FIG. 36 illustrates how a travelling pro gram may be 

FIG. 2 shows an exemplary structure of a travelling designed to be split and send programs to a number of 

program together with its associated components; different recipients; 

FIG. 3 shows an exemplary execution control area FIG. 37 demonstrates how previously split programs 

data structure; 40 may be merged; •'^■m^c->- 

HG^4 shows the data structure of a file control block FIG. 38 shows an alternative approach to merging 

(FCB) which is used when a travelling program at- previously split travelling program information; 

taches files to, or detaches files from itself; FIG. 39 is a flowchart indicating how the travelling 

FIG. 5 shows a process control block that is utilized program has been designed to accommodate electronic 

in the execution of a travelling program; 45 document interchange generation functions; and 

FIG. 6 illustrates a variable control block data struc- FIG. 40 relates to the use of travelling program in 

ture (VCB) which is used for controlling variables; receiving an electronic data interchange transaction. 

™- 7 ^ 80 traveUin8 pr0gram DETAILED DESCRIPTION OF THE 

HO. 8 shows how the header is loaded; 50 PREFERRED EMBODIMENT 

FIG. 9 shows how the "program" segment of the FIG. 1 shows a block diagram showing an exemplary 
travelling p io gran i is loaded; communication system which may be used in conjuno 

FIG. 10 shows how the 'Variables" segment of the tion with the present invention. This system includes a 
travelling program is loaded; communication channel 12 over which communication 

» * FIG.-lLshowshow the "certificate" segment of the 55 between terminals A, B,'. .".'N; may ta^placeVGdnmu- ^ 
travelling program is loaded; ideation channel 12 may, for example, be an unsecured 

FIG. 12 shows how the "file" segment of the travel- communications channel such as a telephone line, 
ling program is loaded; Terminals, A, B, . . . N may, by way of example only, 

FIG. 13 delineates how the "closure" segment of the be IBM PC compatible computers, having a processor 
travelling program is loaded; 60 (with main memory) which is coupled to a conventional 

FIG. 14 represents the operations performed in pro- keyboard/CRT display 4. The processor with main 
cessing P-code instructions; memory 2 is also coupled to a non-volatile storage 

FIG. 15 shows processing which takes place after the which may be a disk memory. Each terminal, A, B . . . 
P-code operation is performed; N also includes a conventional IBM PC communica- 

FIGS. 16A and 16B show processing for handling 65 tions board (not shown) which, when coupled to a 
program defined functions or calls; conventional modem (6, 8, 10, respectively), permits a 

FIG. 17 shows the sequence of operations for han- terminal to transmit and receive messages including 
dhng built-in functions; travelling programs. 
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As used herein, a "travelling program** is a digital for any reason to recompute any material to be verified, 

data structnre which includes a sequence of instructions and to perform a digital signature verification, 

and associated data and which has the capability of The results of such verification can be announced to 

determining at least one next destination or recipient for any recipient, or more likely, the travelling program 

receiving the travelling program and for transmitting 5 can simply perform the verification and announce a 

itself together with all relevant data determined by the problem should there be a failure (which suggests at- 

program to the next recipient or destination. tempted data tampering). 

Each terminal is capable of generating a message and Because the travelling program monitor may embody 

performing whatever digital signature operations may the teachings of U.S. Pat Nos. 4,868,877 and 5,005,200, 

be required to load and execute the logic, data, and 10 it is possible for authorization to also be checked so that 

functions inherent within the travelling program (as any recipient can be assured that the necessary authori- 

described more fully herein), and transrmtting the mes- zations were performed. 

sage to other terminals connected to communication After a particular data structure has been constructed 

channel 12 (or to a communications network (not and signed under control of the travelling program, it is 

shown) which may be connected to a communication 15 possible to subsequently reconstruct that data structure 

channel 12). and to provide its signature to any other entity. Such 

The digital signature and certification methodology data can not be subsequently tampered by any entity, 

described in the inventor's TJ.S. Pat Nos. 4,868,877 and However, the present invention also embodies capa- : ' '-"'*-- 

5,005,200, as well as U.S. Pat No. 5,001,752 may be bility whereby all the tnmsmitted data is digitally signed 

used hfrein, which patents are hereby expressly incor- 20 as it is sent from one user to the next. The travelling 

porated herein by reference. Alternatively, more con- program processor in the recipient's computer can auto- 

ventional digital signature methodology may be uti- matically verify this signature as the travelling program 

lized. is loaded. This assures that no component whatsoever is 

Before describing the details of the * travelling pro- altered or tampered along the way. While this overall 

gram" structure and methodology in accordance with 23 signature only reflects the state of the data during this 

an illustrative embodiment of the present invention, an particular transmission, and has no significance for later 

example of the general operation in an actual business users, it does insure a perfect transmission untampered 

transaction context will be briefly described. Initially, by third parties, and it does provide a forensic audit 

presume that the user of the FIG. 1 terminal A is a mechanism if it is necessary to trace covert tampering 

relatively low level engineer who is a part of a design 30 by participating users, while those users had possession 

team in a corporation seeking to obtain cornponent parts of the form. This overall signature differs from current 

to complete a circuit design project capabilities whereby electronic mail is signed, in that 

The engineer using keyboard 4 would access a parts the signature can be conditionally induced by the trav- 
requisition "travelling program*' of the type to be de- elling program itself; as part of the trarismission process, 
scribed in detail below. The requisition "travelling pro- 35 Ultimately, after all the approvals have been obtained 
gram" will prompt the engineer to describe the compo- within the organizational structure, the travelling pro- 
nent parts needed. The travelling program includes an gram will create an actual Purchase Order, 
instruction sequence which will automatically transmit This could be done in many ways. It may well be 
itself to a next destination, eg., to a supervisor who has possible for a travelling program to support several 
access to terminal B and who is higher up in the organi- 40 methods, choosing the one most appropriate for a given ;ES * y " 
zattonal structure and possesses the authority to ap- circumstance. We describe four possibilities here: 
prove the requisition request and digitally sign it The 1. The travelling program could simply print out the 
travelling program may also transmit ancillary informa- final purchase order on paper — possibly even print- 
tion, such as files which may be necessary or useful at ing the company logo, letterhead, etc. — which 
future destinations. The supervisor will be prompted to 45 would be physically mailed, 
properly digitally sign the request It is possible that the 2. The travelling program, if coupled with an outgo- 
digital signature reflects not only specific variables val- ing computer-to-fax capability, could automatt- 
ues, but also the variable names. Alternatively, the sig- cally generate a purchase order image, that would 
nature may also reflect some aggregate structure which appear on the vendor's fax machine The buyer 
is derived from variables computed within the program, 50 would not have to produce paper, 
wherein the values may be based on any of many 3. If it is known that the vendor also supports the 
sources, including data read from file, user input, data travelling program methodology of the present 
built into the program, various signer's certificates, or invention, then it is possible that the travelling 
data which is extracted from the user environment v program will simply designate the vendpr^asa.next^^p^ ^v^^j 
(such as the- user's ID), etc?^ 1 ^^* ' MA 55 " destination. " " ^ 

If the request is approved, the requisition form will 4. It is also very possible that the vendor does not use 

take a different path in the organization then if it is not the present invention, or that the purchaser's trav- 

approved. The travelling pr o giau i can have the intelli- elling program cannot determine with certainty 

gence to determine, based upon the input from the su- that the vendor is able to handle the travelling 

pervisor at the operating termmal B, where to transmit 60 program methodology. 

itself within the organization. The travelling program Therefore, the travelling program manipulates its 

will also, if desired, load the memory associated with internal data to construct a standardized EDI (Elec- 

tenninal B with the appropriate dam relating to the tronic Data Interchange) transaction, which can be 

requisition and to attach if desired any files from tenni- widely recognized and processed. The travelling pro- 

nal B that needs to be forwarded elsewhere in the orga- 65 gram may also cause a digital signature to be performed 

nixatinn on the computer EDI transaction, and the signature and 

Once a signature has been done, the travelling pro- the transaction can both be transmitted. The travelling 

gram has the ability at any later time, for any later user, program would then transmit the EDI transaction, as 



07/30/2004, EAST Version: 1.4.1 



5,390,247 

. 7 8 

well as any possible signature, to the recipient (Such for example, relate to a purchase order related applica- 
transmission is independent of, and should not be con- ticn. 

fused with, the transmission of the travelling program The travelling program will possess the characterise 
and its ensemble from user to user as part of its directed tics described above including the ability to transmit 
travels.) 5 itself to further recipients. Thus, program 22 will in- 

Any recipient that can handle standardized EDI elude instructions for forwarding itself via whatever 
transactions is then able to handle the received EDI medium is available to one or more recipients. This is 
input Any recipient that can handle digital signatures, known herein as a "traversal'*. One source code instruc- 
ts further able to authenticate the transaction. Further- tion or several P-code instructions may be required to 
more, provided the recipient has sufficient software 10 result in the "traversal" of the travelling program to one 
capability to recognize them, the recipient can also or more identified recipients). The travelling program 
automatically validate any authorization that may be structure set forth in FIG. 2 is designed to be indepen- 
embodied as part of the signature. It is up to the logic of dent of any particular computer architecture and is 
the travelling program the extent to which certificates structured in accordance with international standards 
should be transmitted along with a signed transaction. 15 (e.g., X.209 format). 

In any of the above cases, the travelling program can The travelling program also includes a "variables 
spin off the purchase order (P.O.) information to the segment*' 24. Prior to being executed by a first user, the 
vendor, using any of several possible levels of automa- variable segment 24 may be virtually empty. Once the 
tion. Following this, the travelling program might program is sent to a recipient, further variables will 
transmit one version of itself, or possibly just a letter, 20 become defined as they are required by the program to 
back to the originator, to inform him that the P.O. has thereby result in an increasing number of variables as 
been sent Other information can be sent to an archive, the program is further executed. By way of example 
or to a queue to await further processing. This informa- only, the variable section 24 may identify a variable, 
tion could be a simple message, a record added to a file, such as '*totaLdollars.received" together with an actual 
or perhaps the travelling program schedules a full tra- 25 data value for this variable. 

versal (automatic "mailing" or transmission). Each variable may have associated therewith the 

FIG. 2 illustrates the structure of a travelling pro- information set forth in each of the fields 52-42 shown 
gram together with its associated components in accor- in FIG. 2. Field 32 identifies the size of the variable 
dance with an exemplary embodiment of the present name. The variable name itself is stored in field 34. The 
invention. The FIG. 2 travelling program includes at 30 size of the value of the variable is set forth in field 36. 
least the following multi-field segments. A first header The value of the variable is in field 38. Field 40 identi- 
segment 20 preferably identifies the size of each of the ties the execution stack level to which the variable 
component segments, the name of the associated pro- belongs. The execution stack level is identified since the 
gram (and possibly other segments described below), same variable name can exist at different levels within a 
the date, the type of each component (eg., the program 35 program (e.g., one variable name may exist in a first 
is the source language program, or the program is P- subroutine while the same variable name may exist in a 
code that has already been compiled), the identity of the separate or nested subroutine and yet have a different 
form, version of the interpreter needed to execute it, definition)- The execution stack level is helpful in recon- 
data necessary to resume execution at the appropriate structxng the travelling program in a recipient's corn- 
point of program resumption (such as execution stacks, 40 puter to take on the same logical structure it had in the 
PCBs, etc.), dates associated with the latest traversal, sender's computer. Field 42 is an optional field which 
and program authorization information (PAI). Each may identify a type of variable, eg., strings, octets, 
segment in the travelling program structure may in- integers, etc 

elude its own description so that the "type of each com- The "variables" section 24 may also include a digital 
ponent and size" field "S" would not be included in the 45 signature of the respective variables and related infor- 
header segment 20. For the purposes of the present mation. Thus, it is also possible for one or more vari- 
apphcation, program authorization information (PAI) ables to reflect digital signatures which have been taken 
may be regarded as security information which defines at various times during the travelling program's execu- 
the range of operations that the associated program is tion path. One of the significant aspects of the current 
permitted to perform (e-g., defining access to files, the 50 invention is that the travelling program can create a 
ability to call programs, ability to generate electronic digital signature on any type of information. This signa- 
maH, ability to transmit data to other users, ability to rare is itself carried as a variable. To verify the signature 
release documents, ability to execute machine language it is necessary for the program to indicate (or possibly 
programs, ability to access special areas of memory, _ r recompute) the exact ydue winch was signed, and ^en 
ability to "display information to userK aSifity *u>1ohW'55 pass mat, together with the signature value (also indi- 
digital signatures, ability to access a digital notary pub- cated by a variable) to the VERIFYSIGNATURE 
He device, etc.). Further details regarding the nature function of the travelling program. By including a digi- 
and use of the program authorization information may tal signature of variables, a recipient will be enabled to 
be found in applicants U.S. patent application Ser. No. verify that the data 1) has not been tampered with, 2) 
07/883,868, entitled, "Computer System Method and 60 has been validly signed, and 3) the signer was properly 
Apparatus Using Program Authorization Information. authorized. See above identified U.S. Pat No. 
The header segment 20 may also include a version num- 5,005,200, which describes a preferred mechanism for 
ber of the associated travelling program. associating authority with a digital signature. 

The travelling program code 22 segment follows the A segment 26 is shown in FIG. 2 for optionally in- 
header in the exemplary embodiment and preferably is 65 eluding with the travelling program, certificates associ- 
written in the restructured external execution program- ated with any digital signatures so that any signatures 
ming language (eg., the REXX language) or something may be verified by a recipient as described, for example, 
akin to PASCAL or COBOL. The program itself may, in the above-identified U.S. Pat No. 5,005,200. Alterna- 
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tively, the certificates could be included in the "vari- taches files to, or detaches files from itself. The file 

ables" section together with the digital signatures. control block includes a tag field 116 which identifies a 

Segments 28A-28N contain file images that are re* tag for referencing a particular file to be attached or 

corded and tagged by name to enable the travelling detached in a particular user's system. The file control 

program to attach and store a file belonging to a travel- 5 block also includes a segment 110 which is a pointer to 

ling program user. Thereafter, the user's file may be the next file control block. The file control block also 

transmitted along with other prior user's files with the includes a status segment 112 which H^ffa^ various 

travelling program. The name of the file facilitates later status conditions such as whether the aggregated file has 

accessing of the file by a user and permits the travelling just been attached by the received travelling program; 

program user to identify any file which is, for example, 10 whether the file can be detached on the next traversal . 

to be further transmitted, or which is to be deposited fi.e., next mailing); whether the file has been exported 

with a particular user under particular circumstances. (Le., the associated file image has already been loaded 

The travelling program also includes a "closure seg- into a separate user file); and an indicator as to the "type 

ment" 30 which includes, for example, the digital signa- of file** such as whether the file is stream oriented or 

ture of the entire travelling structure so that the recipi- 13 record oriented. Other attributes of the file may be 

ent can verify that the transmission of the entire travel- denned in this field. 

ling structure has not been tampered with since it was Segment 114 stores an indication as to the file's pod- 
last sent . : . tion within the main incoming travelling program file so 

Having described the travelling program data struc- that die particular file in question may be quickly ao 

ture, we now describe the data structures utilized dur- 20 cessed. Segment 118 identifies whether the local name 

ing the execution of a travelling program and the associ- of the file (Le., the file name identified by the most 

ated software for executing the travelling program. An recent recipient of the travelling program). The local 

execution control area (XCA) data structure is shown in name of the file is typically provided if the file has been 

FIG. 3. The XCA specifies information required by the attached and is being forwarded to a further recipient or 

program which executes the travelling program, once 25 if an already attached file is being "exported", Le., 

the travelling program has been received by a recipient, stored locally by a particular user. Additionally, as 

and compiled into F-code (unless it was originally trans- shown in FIG. 4, the FCB may contain a hash of the 

mitted in P-code). associated file. As will be appreciated by those skilled in 

As shown in FIG. 3, XCA segment 82 identifies the art, a hash is a "one. way" function which should be 

address and size of the program as it appeared in the 30 computationally easy to compute given the underlying 

incoming file. It should be recognized that, throughout data. The hash function should be computationally im- 

this description, whenever a segment is stated as storing possible given a hash value, to either determine the 

an "address" or "location", that the data may be aphys- underlying data, or to create any data which has the 

ical or logical address and need not necessarily directly specified value as its hash. For all practical purposes, 

specify an actual physical memory location. The pro- 35 the value obtained from applying a hashing function to 

gram may be received in source or P-code and an indi- the original aggregation of data is an unforgeable 

cation is maintained. as to which is the case. The execu- unique fingerprint of the original data. If the original 

tion control area includes a segment 84 which is indica- data is rJianggrf in any manner, the hash of such modi- 

tive of the address of the p-code version of the program . fied data will be different 

and its size. The address (or pointer to 'the address) of 40 FIG. 5 shows an exemplary program control block 

the current program control block is identified in seg- that may be used during the execution of the travelling 

ment 86. The location of the list of file control blocks program. A program control block keeps track of con- 

(FCB) which is used, for example, to attach and detach trol information regarding the program being executed 

files associated with the travelling program is set forth in a structured programming context where one routine 

in segment fffl. The address of the certificate control 45 calls another routine, each routine having an associated 

area (CCA) which is used for controlling certificates program control block. 

which are attached to the travelling program is set forth The program control block segment 50 points to the 

in segment 90. The location of the "variable" informa- prior program control block in the program execution 

tion table (VTT) is set forth in segment 92 which con- control stack The program control block includes a 

trols and maintains variables in the form of a "B-tree", 50 segment 52 which defines the next P-code position to be 

which is a hierarchical binary tree structure which executed in the current executing program and segment 

identifies the location of each program "variable". 54 defines the type of last P-code operation performed. 

The execution control area also includes a security Segment 56 includes a pointer to an expression evalua- 
mformation segment 94 which may be used for verify- tion. stack, which is used during expression evaluation, 
ihg the' authenticity ' and the authbrity^ir^licit'm' the 55 The execution stack is typically distinct from the pro- 
travelling program. Segment 96 defines the name of the . gram stack, in that the execu Lion stack is used for evalu- 
file that contains the incoming travelling program ating expressions and keeping track of internal state, 
which may need to be accessed. Segment 98 keeps track Segment 58 defines the level of this stacking program 
of the number of times the program has mailed itself and segment 60 defines a pointer to a list of shared 
along the incoming path. The execution control area 60 variables. In the REXX language an "exposed" state- 
also includes an input parameter section 100, whereby ment may be used for accessing shared variables, 
parameters relating to the execution of the program FIG. 6 illustrates a variable control block data struc- 
may be identified. Execution control area segment 102 ture (VCB) which is used for controlling variables, 
identifies the input header information received from Segment 62 identifies where in the B-tree a variable ts 
the travelling program file so that the header informa- 65 located and may contain several pointers. Segment 64 
tion will be available. identifies the size of the variable value and segment 66 

FIG. 4 shows the data structure of a file control block identifies a pointer to where the value is located in 

(FCB) which is used when a travelling program at- memory. Segment 68 may be optionally used to identify 
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the type of variable. Segment 70 identifies which level In block 172, a check is made to determine whether 

of the travelling program the variable is associated the program has been sent as P-code. If source code 

with, so that after the pr o g r am is executed, any local rather than P-code has been sent, then the source code 

variable which was associated with the program may be is compiled into P-code using conventional compiler 
readily deleted. Segments 76 and 80 identify the size of S techniques known to those skilled in the art and the 

the variable name and the name, respectively. source code image is deleted from storage 174. Regard- 

We now turn to illustrating the execution of the trav- less of the check at block 172, the position in the inccm- 
elling program. The sequence of operations performed ing file of the program — whether it is in source or P- 
by a 'loader" portion of an interpreter execution-driv- code format — is saved in the XCA Knowing the lock- 
ing program is set forth in FIGS. 7-12. These opera- 10 tkm and extent of the mcoming image simplifies the 
tions relate to preparing to execute a travelling pro- copying of the program into eventual outbound traver- 
gram. sal(s). Finally, regardless of whether the P-code was 

A travelling program may execute in one of a plural- just compiled, or whether it was read form the incom- 

ity of different modes such as an interactive user mode, ing file, the main storage address and size of the P-code 

a mode in which it is called by another program, or a 15 is set into the execution control area (XCA) in 178, after 

batch operation mode in which it is sent from node to which the routine shown in FIG. 7 is reentered at block 

node collecting information. Initialization information 124 to thereby result in loading remaining segments 

is input during the start-up operation (120) to identify such' as the 'Variable" segment processing shown in 

the particular operating mode as well as associated FIG. 10. 

run-time parameters. 20 In processing the "variable** segment as indicated in 

The flowcharts set forth in FIGS. 7-12 illustrate how block 190, a check is made to determine whether the 

a travelling program structure shown in FIG. 2 is header and program have been loaded but no prior 

loaded. In loading the travelling program, the inter- variables. If this is not the case, then an error condition 

preter creates the execution control area XCA and results 192. If a header and program have been loaded, 

initial program control block PCB. It saves access to 25 but no prior variables, then we begin an iterate process 

input parameters, saves the names of the input files that to read all the variables, if any. A check is made at 194 

it has been given to load and initializes the variable to determine whether there are (more) variables to react 

information table (VTT) (122). In flowchart block 122, If there are more variables to read, then for each vari- 

the execution control area and program control block able, a variable control block (V CB) is created as shown 

associated with the travelling p ro gram are established* 30 in FIG. 6 and is completed by the insertion of a variable 

The various XCA and PCB fields are filled in during identifier and value into the variable control block 

subsequent processing. (VCB) and the setting of certain status conditions in the 

Thereafter, the loader begins loading travelling pro- VCB. Additionally, the variable control block is added 

gram segments, Le., header, program, variables, certifi- to the proper spot in the variable information table 

cates, file and closure segments as shown in FIG. 2. 35 (VTT), the table which contains all program variables 

Loading each of the travelling program segments de- (196). 

scribed above, e.g^ header program, etc, causes appro- Additionally, other variable information, for exam- 

priate data to be filled in as described below. pie, related to previous executions of the travelling 

In block 124, a decision is made as to whether more program are loaded into memory stacks or program 

segments need to be processed. If so, then the initial 40 control blocks as appropriate 198. Alternatively, it may 

input is read for that segment and the type of segment is be desirable to keep such "control" information in the 

determined after which segment processing is initiated header segment rather than here. Thereafter, the rou- 

depending upon the type of segment (126). tine branches back to block 194, where checks are made 

Turning to the header processing of FIG. 8, initially, to determine whether more variables are required to be 

a check is made to determine whether the segment 45 read. The processing continues until no more variables 

being processed is the first segment (150). If not, then an need to be read, at which point the routine branches 

error condition exists (152) since the header must be the back to block 124 of FIG. 7 to thereby result in loading 

first segment If the first segment is being processed, the next segment 

then the header is read and hashed. The header data is As indicated in FIG. 11, ™<*h certificate is read (200) 

stored into the XCA (154). 50 and a certificate element is created which is then added 

The routine then branches back to FIG. 7 at entry to a certificate control area (CCA) in storage (202). As 
point L. The loader determines whether there are any schematically indicated in FIG. 11, the process is re- 
more segments to be processed (124). If so, block 126 is peated untfl all certificates are received at which point 
executed to result in the processing of the "progr a m*' the routme brancto back^ 

se^entasshbw^ 

detennine whether there is a header, and no program Alternatively, it may be desirable to transmit the 

has yet been loaded (160). If the answer is no, then an certificate segment ahead of the program segment, so 

error condition exists (162). If the answer is yes, then that certificates used as part of program authentication- 

the program is read and a hash is taken (164). /authorization can be rnaintained together with any 

Thereafter, the program hash and/or digital signa- 60 certificates used by program variables and user-to-user 

tures associated with the program (and/or the header) authentication. 

are verified 166. If the digital signatures were not prop- This branching operation results in the "file" segment 
erly authorized or could not be verified, then an error processing shown in FIG. 12. Since the file segments 
condition results 166. If verification occurs, then any typically follow the 'Variable** segments, a check is 
security and authorization information associated with 65 made to determine whether the variable segment (even 
the travelling program is saved (170). Such authoriza- if null) has already been loaded. If not, then an error has 
tion information could alternatively be kept in the been detected and an appropriate error message is gen- 
header or in the program segment erated 212. If the "variable** segment has already been 
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loaded, then as_ indicated in block 214, a check is made to the program when its execution is restored on the 
to determine whether the file tag associated with the tile recipient's machine. The travelling program can then 
has already been loaded. If so, then an error is de t ected test this value to distinguish the situation. Another way 
indicating that the file has been duplicated 216. this distinction could be made is by providing the trav- 

If the file tag has not already been loaded, then as 5 elling program a function to extract the "number of 
indicated in block 218, a file control block is built for the prior traversals" (segment 98 in the XCA). Before ra- 
ffle, the tag name is set, other status indicators are set yoking the traversal, the program could use this ftmc- 
that may have already been associated with the travel- tion to save the prior-traversal<ount functkm. If it 
ling program, and the file position is set relative to the matches the value of the variable, then the program 
uicoming file. 10 knows the execution is resuming in the sender's corn- 

Thereafter, the file is read and rtehash is computed puter tf h differs (and it should only be one greater), 
and saved m segment 115 of jti* -FC^Tfce ste of the ^ ^ ^ws the execution is rescuing at 

file is saved m segment 114 of the FCB. The file need ^ recipient's computer 

not be loaded mtomemory at th* time $20). Thereaf- When the first user generates the travelling program, 
^n^Snt^^^ 'SlE? T^f 15 the loader routine shown in FIG. 7-13 is J^rth 

h! the file control block tet "fleeted m the XCA f perhaps no, variables, files, or certificates. 

and the routine branches back to block 124 to process a I i- i ZZZ- * v , X_ 

the next segment (probably "closure"). Accord^y certain of the atove^escnT>ea^ wfll 

In the^c^^pro^ 13, the hash is *»W ^ I processmg. The loader 

computed of an ^ouTSes for eachprevious seg 20 Z^^T^t TZf^S^ * 

ment (230). It should be recognized that all the "seg- ****** f ° r the first tune or executed by further recipi- 
ment" material is read subject to hashing. A check is ^ytt^ ^ . . 

then made in block 232 to detexininTwhether the hash HG * l 4 ffl V st ^ atcs operations performed m pro- 
taken and calculated in 230 matches the hash added f 33 ^ P ^ mstru ^f ; A rt .^ repeated for every 
when the travelling program was sent (which is stored 25 l f trn f? on «ecuted. As indicated m block 250, 

in the closure segment). If there is no match, then an lo f taon of L?* 0 ? n ? structlon * denved 

error condition results 234. from current FCB (52), and this becomes the "cur- 

If there is a match, a check is made as to whether the ""^ PHCode °P erat ion. In block 252, the length of this 
travelling program is signed (236). If not, then as sug- P-code operation is determined, and the "next P-code" 
gested at block 238, an action is taken to incorporate 30 Portion (52) is updated to reflect the subsequent P-code 
whatever level of security is desired, such as possibly instruction. The type of the current P-code operation is 
presenting a notification that the transmission data is not raved " t 54 ) d* is useful for the interpreter to share 
entirely signed (238). common routines which have slight variations based on 

If the transmission was signed, then the signature is the precise operation. For example, the "call" operation 
verified and a message is presented to the user to accu- 35 811(1 the "function invocation" operation are similar 
rately identify the party who actually sent the travelling except that the function invocation expects a parameter 
program (and the associated purchase order or other to ^ returned). 

form) 240. The routine then branches back to block 124 Thereafter, as illustrated in block 254, the indicated 
of FIG. 7. P-code operation is performed. Most P-code functions 

w^The completion of the "01050X6" processmg in FIG. 40 involve data inaiupulation^logical tests and program 
13 results in block 124 determining that there are not & ow control By way of example only, such P-code 
more segments to be processed. Thereafter, a check is operations may include locating a variable and pushing 
made to determine whether closure was successfully the variable in a stack, resetting the next P-code opera- 
received and processed (128). If it was not, then the tion to thereby change the flow of control such as 
routine stops execution after performing an unsuccess- 43 would occur in a branching operation, performing an 
ful validity check (130) and processing halts 132. arithmetic or string operation, performing IF/THEN- 

If the check at block 128 reveals that closure was /HLSE oper ation based on the popped stack value, 
successfully completed, then various steps are taken to perform DO/ITERATE/UNTIL/WHILE, or other 
prepare far program execution (134). In this regard, operations based on stack values, performing SE- 
stacks are restored, the variable information table and SO LECT/WHEN/OTHERWISE operations based on 
variable control blocks are restored. The program con- the stack values, performing an "END" operation to 
trol blocks are restored such that they contain the exe- close a DO/WHEN/SELECT operation, 
cution resumption point We will soon discuss in some detail various P-code 

Thereafter, the routine .shown .in. FIG. .14 is initiated operations pertinent to the present invention's unique 
'to actually process the P-code instnictk>nsl Thefollow- 55 operation: With tie guidance'^venTierein, the P-code 
ing problem must be considered here. Because the pro- functions can be implemented in a straight-forward 
gram execution is effectively, restored identically to the manner by anyone familiar with writing interpreters, 
state it was at the time it was transmitted (as part of the However, ignoring for the moment the details of the 
traversal) from the sender's machine, there is an issue of particular P-code function, the preferred design allows 
how the travelling program can distinguish whether it is 60 for P-code operations to generate logical "mterrupts" at 
in the sending ™»^hrn r, and just returned from the send- their completion. 

ing itself; or whether it has just been restored in the These allow processing P-code processing to be sus- 
recipient ma c hin e. pended while some other, external operation must be 

The present invention allows multiple ways to ad- performed. This interrupt concept is used in the pre- 
dress this problem. If the traversal function is irnple- 65 ferred design to facilitate the rollout of working storage 
mented as a built-in function, then the interpreter will whenever lengthy waits or external activity is invoked, 
return a special value (say "0") to the program after it In FIG. 15, on return from the P-code routine in 
has successfully sent itself, and another value (say "1") block 256, the interpreter determines whether the rou- 
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tine has signaled a logical interrupt. If not, then return is stack, the VIT, the XCA, the* P-code itself, and any 
made to 250 to handle the next P-code operation. other blocks, to some auxiliary storage (such as a file). 

If an interrupt was indicated, a special check in block The interpreter itself may be released from storage, and 
258 is made to determine whether this is the special this may be done in a special block (264), provided that 
"EXTF* request If so, then all resources which should 5 sufficient residual program and data remains to later 
be released at the end of this program, such as storage, reload the interpreter and the working storage, 
files, variables, load subroutines, eta, are discarded in in step 266, the inter-rollout routine is invoked. Typi- 
block 260. A possible return value from the P-code cally, this routine waits for the user to enter input, or to 
operation, which may have been saved by 260, is re- wa ft until a future time or other event, or to invoke 
turned in block 259 to the invoker of this travelling 10 another program which might wait for input, or cause 
program. other delays, or require a large of storage which is 

Assuming, this is not EXIT, then block 261 deter- vacated by the ROLLOUT 
mines whether ROLLOUT should be performed. For ^ block 268, after the inter-rollout is finished, the 
example, in certain envir^oimient^ it is useful for work- interpreter is reloaded, then the working storage, in- 
ing storage to be rolled out while a user completes 15 cludmg the P-code, the execution stack, all control 
entering input, or whfle the travelling ^program is wait- blocks ^ stored from auxiliary storage. 

? S *f l^f J**"' 31 to e ?" rf Z!l ^IL 16 ^ ( u Then in block 270, any mial accessing is done to tidy 

krge) external program has been ^invoked from the ^ operatioiL For examfde, to^icafly include; 

travdQmg^)gram logic or whfle the dimtal signature ^ ^result returned bythe mter-rollout routine to 

routine is being executed (since that often involves user 20 ♦uIl^L^ ^ v 1 , "JZT i77ku. 
innufl the execution stack, or to a program Variable^ 

Routines which cause a P-code interrupt and a possi- ™ ^ °°SK * ^ ST 

ble ROLLOUT, regardless of whetherTy are imple- ^ p^^^^^^ ^ whae * C 

mented as built-in functions or as language statements *ext P<ode instruction is processed, 

(with their own P^ode), include: 25 We now exarnine ^Jj^eopenUons of interest 

SIGN which applies a digital signature to any com- T^?^ preferred ^otoent handles 

puter data, and in doing so may solicit the user to "* faaetiaa: to . routin f? wmch ™ 

select from multiple certificates, and solicit the user ^ mll ' m to interpreter, to routmes which are wnt- 

to provide his secret password key which allows P 3 * of *^ travelling program, and to routmes 

the private signature key to be decrypted and used; 30 which are external to the interpreter or program, and 

DISPLAY compose and output a screen and wait for which ™ dynamically located and invoked when the 

the user to supply input; program is executed. 

TTMEWATT suspend execution until a future time is In FIG. 17 we see that the built-in function appears 

reached* rather simple, and the interpreter simply locates the 

SELECT J7ROMDIRECTORY which allows se- 35 specified function based on an index in the P-code, and 

lection from, e.g., a directory of users, or a direc- lookups the routine's address (within the interpreter), 

tory of files, etc. and calls it However, it is important to realize that, 

NOTARIZE wait for a time notary device to apply while most do not, some built-in functions might signal 

its own digital signature. a P-code interrupt In this case, the built-in function 

In some environments, ROLLOUT is pointless, and 40 must provide tte. necessary pre-rollout, inter-rollout 

in these cases the rollout and rollin processes in block m & post-wait routines. 

262, 264, 268 will be absent or inhibited. The P-code interpreter always distinguishes CALL 

In any case, a P-code operation which signals an an & functions, and provides for the return of a result to 

"interrupt** also supplies the address of at least 3 associ- the execution stack in and only in the case of a function. 

ated ("call-back**) functions 45 For example, the SIGN function returns a value which 
the pre-rollout routine, which performs any required represents the digital signature computed on the sup- 
functions in preparation for rollout Tins might plied data. 

include preparing a parm field in temporary stor- la FIG. 16A we see that a call/function to a program 
age to pass to . . . routine causes the creation of a new PCB execution 
the inter-rollout routine which executes after as much 50 level 300. The new PCB is set to start executing at the 
working storage as possible has been rolled out to start of the subroutine, by setting the next-P-code in- 
auxiliary storage. struction (52) to the P-code entry point of the routine, 
the post-wait routine which handles details following The first instruction of the routine will be accessed 
the rollback after the inter-rollout routine is fin- when block 250 is reentered. Parameters are prepared 
: - z isfceH, anB'after workmg storage has been restored 55 for the program romine, ;f aprjropria^ staluS condition 
from auxiliary. Typically, this involves copying a are set, the program level 58 in the PCB is set to one 
result value computed by the inter-rollout routine higher than the calling progr am and the PCB is placed 
which is left in temporary storage, and which must at the top of the execution stack as the now current 
be loaded onto the execution or copied into a pro- PCB (82). The result of a program routine is passed to 
gram variable. 60 the caller through the P-code RETURN operation. 
In block 261, the pre-rollout routine is invoked This In FIG. 16B, we see how the corresponding program 
may be a null routine, or it may setup, e,g„ parameters RETURN P-code operation operates. Block 1200 de- 
for the inter-rollout routine. terniines if a RETURN is made from the highest (only) 
In block 262, the rollout function is performed, if level PCB, in which case this operates as an EXIT, and 
appropriate given the environment and circumstances 65 block 1204 signals that a P-code "EXIT" interrupt is 
If done, then ROLLOUT consists of writing all work- required and passes the return RESULT (if any) as the 
ing storage, including the VCBs and their values, the value to eventually be returned by block 261 (FIG. 15) 
FCBs, the certificates and the CCA, the execution as me RESULT for the entire program. 
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Otherwise, in_block 1204, determination is made as to It is possible that the external routine is actually an- 

whether the invoker used a CALL or function (e.g., by other travelling program. If so, then special optmrizar 

checking field 54 in the caller's PCBX and in the latter tion may be performed by using the existing already- 

case block 1206 puts the return VALUE on the stack loaded image of the P-code interpreter, and simply 

(or creates a default value if the RETURN had no oper- 5 passing a new set of parameters to block 120 (FIG. 7). 

and). In this, special logic would need to be inserted in blocks 

In block 1208, the current level is cleaned-up, and all 262 and 264 to conditionally avoid releasing the inter- 
resources, including storage, files, variables, etc private preter code itself. 

to this subroutine (aka "program level' 1 ) are released. Now let us turn out attention to various special built- 
Resources, such as variables which are shared with the 10 in functions which are used by the present embodiment 

caller are NOT released and are available. Many of these could be executed either as built-in ftmc- 

In block 1210, the current PCB is then released so tions, or as language statements with their own special 

that the caller's PCB now becomes the current one, and P-code operation. 

return is made to block 256 where execution resumes. FIGS. 20 and 21 illustrate the operations which are 

The interpreter includes built in routines which are 15 performed when a travelling program transmits itself to 

designed to accomplish specialized travelling program a predetermined recipient In block 398, any program 

related functions relating to providing digital signa- authorizing information is first checked to insure that 

tures, user files to\the travelling program and other ^ e traversal operation is permitted. (It is conceivable 

functions to eliminate the need for a travelling program **** SQme travelling programs may not be permitted to 

designer to be concerned with programming such func- 20 travel— but simply to do some function which termi- 

tions. nates at the first use). In the rare case that the program 

P-code operations may also involve the performance fa not to travel, a special return code is pres- 

of a RETURN function which will affect program to ^ caUer 

control, a PROC operation which relates to program Jf 6 present embodiment implements the "TRA- 

control block, The interpreter also performs a DIS- 25 Y^T °P eratk)I1 85 a built - m function. Furthermore, 

PLAY operation which utilizes the interactive display faa f^ isde&ied to return "O" to the immediate 

methodology/language described herein. The inter- ^ 0 ^!j***^ «* 1 ***** 

preter also performs a TRAVERSE operation which * °J!j he recipient's computer. As 

results in the 'Wiling- of the travelling program to ™ ^Plamed this difference m return code allows 

another recipienTTwdl as all associated I cteta. 30 **. to d f eramate tetween * e seade ^ s 

FIG. 18 illustrates an exemplary the sequence of "SP? ™ n ? p , M A _ AOTMBa ^_ . 

operations performed for eSu^extern^toctions ^^^"^ ^i* 5 f ^ 
„ u o_ v -l i c ^ « . . tirst pre-loads the value 1 on the execution stack. 

^A^^t^TZ^"" 1 b0fl w kno^that the stack is transmitted intm^This^e 
?£?£TftZ ^lll^^ S J'^r m S 33 vatae ^ be returned when the travel- 

^^^f^^t^T ling program is reconstituted and restarted on the recip- 

toc^M can is locate fcoin any of several possible ien f s computer. Then all relevant variable data such as 
noranes the 'Variable" information table, process control 

totl fS V^^l {fS^^ PIOg T v blocks - various stacks, variable con^locS are 
SSSJl f&SttZZL* 40 coUected mto * transmission format soch'W a 'format 
may, if desired, be made to determine whether the pro- shown in FIG 2. 

£T ^*te *nw3Xrt or some default action be ^ at block 402, the travelling program 

performed 358. If a decision is made to terminate, then header ^ constructed and transinitted. T^ travS 
an error message is generated, and after various program is transmitted segment by segment, although 

^^^u^^ 0 ^ 0 ^]^^ 35 ^ 45 could, m fact, be transmitted^ 
scribed above .the pro^isjexited (360 362) or any other way if desired. Preferably, a hash is taken 

If the check at block 358 indicates that a default ao of each segment as it is transmitted 
tion should be taken, then the default action is taken, Thereafter, in 404, the program and any authorizing 
e.& , by returning a special default function value (368) information from the input file received with the travel- 
and the routine branches back to node 0 in FIG. 14 to 50 ling program is then copied to the output transmission 
begm executing further P-code instructions. file. The 'Variables" segment is then transmitted includ- 

If the program is found as a result of the check made ing the name, current value, and relevant status of each 
in block 356. then parameters are constructed by the variable (406). Any certificates which were collected as 
program (364). Invoking external routines ; involves a ^ part of performing digital (authorizing) signatures dur- 
PK»demterrupt;witfr*^^ 55 *mglhis'or previous traversal are th^ teSisnSt^^ 

to conserve storage in multi-user swapping environ- Thus, any time a digital signature operation is per- 
ments if the external program is lengthy, or in any envi- formed, all the associated certificates are collected and 
ronment if the external routine is huge and therefore the transmitted in the certificate section of the travelling 
storage used by the travelling program should be va- program 408. The signatures are mamtained as variables 
cated in order to satisfactorily perform the external 60 within the program (Lc within variable control 
program. In this case, the P-code interrupt is signaled in blocks). Certificates in the presently preferred embodi- 
block 366. The indicated PRE-ROLLOUT routine ment are treated as material which can be accessed via 
copies the parameters to the external form the stack (or built in function calls. 

variables) to temporary storage. The INTER-ROLL- Alternatively, it would be possible to include in the 
OUT routine invokes the EXTERNAL routine and 65 certificate package even those certificates which relate 
receives any returned result; and the POST-WAIT to the signatures of the overall transmission and sig- 
routine copies the returned result to the stack (if the nature(s) which authenticate and authorize the program 
external routine was invoked as a function). itself. However, this would require that all the certifi- 
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cates definitely be known at the time the Certificate returned to the current caller to allow it to distinguish 

segment was written, and the logic, and possibly the itself. 

position of the segments would need to be re-ordered to Because creating a digital signature typically involves 

insure optimized processing. user interaction — such as possibly selecting a certificate 

In our implementation, we prefer to keep the certifl- 5 and opening the private key, or asking the user to oper- 

cates associated with the program's authorizing sign a- ■ ate his digital signature token device— the material de- 

ture with the program authorization information in the scribed in FIG. 20 and 21 will actually operate in the 

header or program segment, and the certificates for the preferred embodiment as P-code interrupt routines. As 

user-to-user transmission signature authentication with an example, the TRAVERSE function code would 

the signature in the closure segment. 10 trigger a P-code interrupt, in which the logic from 

After the certificates are transmitted, all file control blocks 399 to 430 would operate as a PRE-ROLLOUT 

blocks are examined resulting in the examination of all routine, while the block at 432 might operate as a IN- 

ffles which may have been transmitted during prior TER-ROLLOUT routine since it may require the 

traversal and any newly attached files 410. A check is aforementioned user interaction. The blocks thereafter 

then made in block 412 to determine whether there are 15 (434, etc) would operate as a POST-WAIT routine, 
any more ffle control blocks to examine. A check is then ^ ^v^g program ^ te designed as desired to 
made at block 414 to determine ^hether any file being ^ numerous ^ daiiRg ^ execution to 

e ^^^^^f d ^ te , d ^ ed i 1 t If ^ C various recipients. In such multiple transmissions, the 

routuie brancto back to 412 and nmther die file, nor the variables ^ ^ prior to each transmission as 

file tag » copied for t^mission. If the file is not sched- 20 appropriate. In this fasmon\ the program in the position 

uled to be detache^ then the file tag name is copied mto ^ G processing distinct for each recipient in a banner 

the transmission 416. which Tfe imr^mentation dcrjendent. 

A check is then made to determine whether the file in wm^e Kupicmcniauon acpcnacni. 

T^^T ~~ ' . . w „. mo in pjQ 22 illustrates a sequence of operations for at- 

that it was part of the incoming traversal, then aU file responds to an menUfied file tag and an identi- 

attributes from the mcornmgWversal as well as the file 6ed Ke name. As inaicated at block 440, a check is 

itself is copied to the outbound transniission file (422). made to determine whe^er a file control block with the. 
This input file name may be accessed via the execution * ^ P*™ 003 ^ with the 

control area XCA and the input position of the file is 30 " delet f i J ^ .... 

associated with the file control block 422. Thereafter, a check is made to determine whether the 

If the file is not part of an mcoming traversal but specified file name reflects an existing file which is ac- 

rather was attached during the travelling program exe- cessible by the user. In this regard, the travelling pro- 
ration, then the file, the file type, and its attributes are 06 a ? sociated program authorization 

copied into me transmission file 420. Thereafter, the 35 information which defines the range of operations 

routine branches back to block 412 to determine which the program is able to perform, including the 

whether there are any more file control blocks to exam- abilit y *> access files. Such program authorization infor- 

ine until all file control blocks have been examined. mation will be checked to determine whether the file 

As indicated in FIG. 21, when all FCB's have been namc » accessible. If the file name is not accessible by 

examined, a check is made to' determine whether an 40 ^ user » 1 ^ sn 311 61101 code/message is returned to the 

overall user-to-user digital signature has been requested user 

is required by the system program 430. Such an overall ^ the file name is accessible to the user, then a file 

signature would be useful in detecting tampering with control block (FCB) is built with the specified tag and 

transmitted information. file name and the file will be attached during the next 

If an overall digital signature is to be taken, then a 45 aQ d subsequent transmission of the travelling program 

digital signature operation on the hash of all material ^ The routine is thereafter resumed with an indica- 

transmitted is performed (432). The digital signature ti° n that the file has been attached successfully, 
operation may be performed in accordance with the FIG. 23 illustrates how a file is erased from the user 

teachings of U.S. Pat No. 5,005,200 (or more conven- system. When an "erase" function is attempted to be 

tional digital signature techniques which do not have 50 executed, security codes are checked to determine 

the associated authority verification attributes, as de- whether the program is authorized to perform such an 

sired). As indicated at block 432, a hash was previously operation (450). If the security codes indicate that the 

taken for each part of the transmission. It is noted that program is authorized to erase the specified file (452), 

alternatively, a hash may be taken of each of die hashes. then an erase operation is performed and the routine 

The digital righaturelii^n^'m^ branches back 'with an indication whether the file was" 

to perform the signature. successfully erased 454. Alternatively, if the program is 

Thereafter, validation is supplied at the end of trans- not authorized to perform an erase operation, then the 

mission as the "closure" segment The validation is calling routine is returned with an error message indi- 

supplied by transmitting a hash reflecting prior mate- eating that the file could not be erased (456). 
rial. The signed hash should demonstrate user-to-user 60 FIG. 24 illustrates the sequence of operations per- 

authentication 434. Any certificate necessary to validate formed in detaching a file from a travelling program. As 

the final signature, which are not already in the certifi- indicated in block 458, a check is made to determine 

cate segment, should be included in the CLOSURE whether a file control block exists for the identified tag 

segment Thereafter, the transmission is closed 436. associated with the file to be detached. If no FCB exists, 

Finally, in block 437, the value "1" which was previ- 65 then the main routine is returned to with an error mes- 

ously loaded onto the execution stack for the benefit of sage indicating that the file could not be detached 462. 

the transmitted program when it arrives at the recipient, If the file control block does exist as determined at 458, 

is removed and replaced with the value **0" — which is then the file control block is deleted at 460 and the mafn 
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routine is returned to with an indication that the file has 
been successfully detached 

FIG. 25 delineates the sequence of operations per- 
formed when a file is to be "exported", ie^ transformed 
into a user file. A travelling program may tpvp a speci- 5 
fled file, for example, representing a spreadsheet and 
convert such a file to a recipient user's, file that remains 
with the user even after the travelling program has been 
sent to a farther destination. The file to be "exported" 
will be identified by a tag and an output file name and, 10 
if desired, a rewrite indicator identifying whether the 
file may be rewritten. 

A check is initially made as to whether a file control 
block exists for the specified tag 499. If no FCB exists, 
then an appropriate error indicating code is generated 15 
and the calling routine is returned to (504). If a FCB 
does exist with the specified tag, a check is to 
determine whether the file is part of an incoming travel- 
ling program 500. If the file to be exported was not part 
of an mcoming traversal, then it must have been at- 20 
tached by the user and already be present in the user's 
file and, accordingly an error message is generated 
indicating that one is not allowed to export a newly 
attached file 502. If the file was part of the mcoming 
traversal, then a check is made to determine whether 25 
the specified file already exists (480). If so, then a check 
is made at block 482 to determine whether it is okay to 
rewrite the specified file. The check includes determin- 
ing whether the program is allowed to modify the speci- 
fied existing file (if no "overwriting"), or to erase and 30 
create the specified file (if "overwriting" is permitted). 
If not, then the block 484 is used to return an access 
error to the program. If the check at 482 indicates that 
it is okay to rewrite, a determination is made as to 
whether the file should be overwritten or whether new 35 
material should be added to the end of the file (486). If 
overwriting is indicated at 486, then the existing file is 
erased (488). A new file is created, if permitted by pro- 
gram authorizing security information and preparations 
are made to start writing at the- beginning of the file 40 
(490). 

If overwriting is not indicated at 486, but new mate- 
rial data is to be added at the end, then preparations to 
start adding at the end of the grating file are *naH^ as 
indicated at block 492. Thereafter, the data is copied 45 
from the correct position at the mcoming traversal file 
to the output file (494) and the main routine is re- 
entered with an indication that the exporting operation 
has been successfully performed (496). 

FIG. 26 illustrates an exemplary sequence of opera- 50 
tion performed when material is to be digitally signed. 
In implementing the digital signature function, initially 
a check is made to determine whether a digital signing 
operation is permitted by the program abjudicated ,at -;r . 
block' 510. Whether a program is permitted to perform 55 
a digital signature operation will be controlled by pro- 
gram authorization information which is associated 
with the program and which is monitored every time 
the program is executed to ensure that unauthorized 
operations are not performed. If the digital signature 60 
operation is not permitted, then an error message will be 
generated rejecting the digital signature function call 
511. 

If the digital signature operation is permitted, then in 
block 514, the SIGN function prepares for user interac- 65 
tion by moving an image of the data to be signed, to- 
gether with any parameters (such as any required autho- 
rization for the data content) to temporary storage in 
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preparation for receipt by the INTER-ROLLOUT 
routine (shown in FIG. 27) which will perform the user 
interactions associated with performing the actual sig- 
nature. 

In block 512, the P-code routine is signalled, with 
interrupt routines which are described below. 

If the digital signature authorization is authorized, 
then a display panel must be presented to the user to 
solicit which certificate is to be used for the signature 
operation. The signature operation is preferably per- 
formed in accordance with the inventor's U.S. Pat No. 
5,005,200 which patent has been expressly incorporated 
herein by reference. The user may possess a wide range 
of certifica t es for performing digital signature opera- 
tions including those constructed along the lines of U.S. 
Pat No. 3,005,200. The INTER-ROLLOUT routine is 
given control at block 509 after much of the storage is 
rolled out (the signature routine itself must remain in 
storage, of course). 

If there are no certificates suitable for perforating the 
signature, then control passes to block 515 which gener- 
ates an error indicator to be returned to the sign opera- 
tion. If there is only one certificate suitable for perform- 
ing the signature, then it is automatically passed to 
(513). If there are more than one suitable certificates, 
then the user is asked to select (516). If the user declines 
(517), then this an appropriate error indicator is gener- 
ated, and passed to the program (515). Otherwise, the 
chosen suitable certificate is passed to (513). 

The associated private key is then located (513). If 
block 518 determines that it is located on the user's 
token, then step (524) is used to solicit communication 
to the token so that it can perform the digital signature. 
Otherwise, the user's private key is located in the sys- 
tem encrypted under, a secret password phrase. The 
user is solicited (520) for this password, which is used to 
decrypt the private key. Any errors or bad passwords 
are detected, an appropriate error message is generated. 
To inhibit guessing by someone other than the true user, 
only a limited number of tries to give the correct pass- 
word are allowed. 

In block 522, the password is used to decrypt the 
private key, which in turn is used to sign the message, 
according to the necessary authority. After the opera- 
tion, all traces of the secret material is erased, and the 
signature and certificate are returned to (268, FIG. 15) 
in temporary storage. In (270) control is then given to 
the POST-WATT routine (530) which moves the signa- 
ture from temporary storage to the execution stack. 

In block 532, the operation is checked, and if it was 
successful, the proof hierarchy for the signer's certifi- 
cate is obtained. Certificates are added to the overall 
certificate collection (maintained in the XCA (90, etaQX. 
if they do not already appear. 

FIG. 28 illustrates the sequence of operations per- 
formed when displaying information to the user. The 
travelling program has associated therewith a display 
layout capability which is described in conjunction with 
FIG. 28. The layout capabilities of the travelling pro- 
gram adapt functions heretofore associated with type- 
setting applications for use in a user interactive display 
mode together with additional enhanced capabilities. 

The screen may be laid out such that input fields can 
be readily moved and associated with various attributes 
for very flexibly interacting with the user. Various dis- 
play related operations and functions are summarized in 
block 540. The display presents an output based an a 
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specified layout definition process controlled by the FIG. 29 delineates a sequence of operation performed 

display processing portion of the interpreter. by a time delay routine. The time delay function may be 

The display processing involves analyzing condi- utilized to wake up at predetermined time intervals and 
tional attributes and static attributes for the fields and check to see whether any incoming electronic mail has 
the group of fields in the layout definition. In the display 5 arrived and attach itself to that mail to thereby co- 
processing subroutine, variable substitution and itera- ciently handle incoming electronic data interchange, 
tion using conditional logic is performed as necessary. Thus, though such a time delay mechanism, a travelling 
Although variable substitution is permitted, the system program could examine a particular maO box at prede- 
retains association between an input variable and where termined time intervals to check whether any mail has 
the field is to be displayed on the screen in the corre- 1° arrived. If the mail has arrived, the travelling program 
sponding variable control block (VCB) even if the field could send the mail to a destination to be handled by a 
is flowed into its final output position as dictated by the further recipient Alternatively, the travelling program 
layout definition. could examine incoming data (such as mail), and based 

The following attributes are then provided to each on various content indicators, automatically perform a 
field tnrJnriinft color, font, boldface/italics, style, size, 15 Averse and spawn a new "instance" of itself which 

underlining, blinking, reverse video, non-display (e.g. } treat the mail appropriately. Of course, the origi- 

for hiding passwords), high intensity display, etc. Addi- ^ "instance" could continue executing and process 

tionally, possible error messages are inserted where every instance that arrives. 

appropriate for a detected error condition and the For exam P le » tf ^ rooming information happened 
proper cursor position is indicated. 20 to be EDI transactions, then a travelling program could 

The layout language used in block 540 permits not read information (using, for example, a READ built- 

only the definition of a screen output but also definitions m ftmcdon )' break u a P art internal variables, deter- 

for accepting input As indicated in block 542, fields are ^ by whom it shouldbe processed and perform the 

written to the user's terminal allowing input fields, as ^ fPP^P™*: traversal. Once successfully routed, the 

appropriate depending upon the application. As previ- 25 letter could be disposed, moved or archived, the pro- 

ousry described, data structures may be rolled out to clear * vambles ' lookm S for 

auxiliary storage (544) and rolled back (546) after the m0 /t mpU Jr , * ^ ^ _ 

user performs data entry into the appropriate input ^T^J afto determmmg the type of material 

g e j ( j s ^ * v arrived, it could invoke another program to process the 

To dotted the step 544 actoaDy involves signaling a 30 i ™*T 8 d * SL U ?™S™* happened to be a 

P<ode interrupt. ShavmgTblSck S^eKrf* SrS^E -ST 

, ixrrm> r>rvrr atit j ui i the necessary input information, and could then TRA- 

the associated INTOR^LLOUT routine, and block VERSE itself appropriate to the handling. 

546 executed as ^^Arr routme^ns^le ^ ^ ^wffor example^^elling pre 

for mapping the mput fields back to the VCBs for the 35 gram to act as a automan^muto for mcom^La, 

associated variables. This may involve passing data ^ „ EDI transactions, and then hand off to other 

through temporary storage, travelling programs the transactions which ft is not 

Thereafter, the mput is analyzed and the mput data is prepared to handle itself, 

msertedm aUj^sociated variables. A fidd validation is Furthermore, if the EDI were signed, then the travel- 

then performed for all input fidds 548. Thu^ ^heck 40 ling program could verify the signature immediately. If 

may be made to make sure that for numeric fields only the signature were valid, and especially if it were done 

numbers have been entered. Similarly, a check may be according to U.S. Pat, No. 5,005,200, then the author!- 

made to determine whether an mput field has the speci- zation for ^ coxM ^ ^ S[3mmBiic ^ y 

fiedattnbutes. screened, and the travelling program could automati- 

Thereafter, a check is made at block 550 to determine 45 cally spin-off an instance to handle the incoming trans- 

whether there has been an error in any field. If there has action* 

been an error, then an error message is produced and For example, with proper enhanced authorization, an 
the cursor is positioned to the errant field (552), after naming Purchase Order could be automatically and 
which the routine branches back to 540 to generate an instantly routed to the shipping department to corn- 
error message display. 50 ^ence fining 

If the check at 550 fails to reveal an error in a particu- items which arrived which were not signed, or which 

lar field, then a further check is performed to cross used simple signatures rather than authorizing sdgna- 

verify that the fields are correct in context (e.g., al- tares, could be routed to various clerical persons for 

though two adjacent fields may be correct individually, exception processing and more detailed inspection, 

"an error condition may be defined regarding the'eombi-" 55 " : As iidlcate^ in block 570^tnelnne delay routine/sets 

nation of fields) 554. Based on a cross verification, a the system alarm clock for a specified time. Thereafter, 

determination is made as to whether the field contains an optional roll out of data to auxiliary storage may be 

an contextual error. If not, then a return is made to the performed (572) by scheduling a P-code interrupt with 

caller 558. If there is a contextual error then an error, appropriate routines followed by a performance of a 

message is produced in accordance with block 552. 60 roll-in of data after the specified time period has 

It should be noted that verification of both the indi- elapsed. Thereafter, a return to the calling routine oc- 

vidual fields is completely under control of the pro- curs (576). 

gram. There may be various specifications, utility rou- FIG. 30 which shows the sprpifnre of operations for 
tines and other conveniences to sinrolifying handling a "select from directory'' function. The directory could 
common situations, but in general, any possible valida- 65 be a directory of files or a directory of user's, etc Ini- 
tion is possible. Cross-validation of fields may involve tialfy, a list is created of aU candidate items 580. There- 
more semantic concerns, and is thus more likely to after, a display is generated to display at least part of the 
require specialized programming. list 582. The user will have an opportunity to select 
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among those items presented (583, 585), after which the 
function will return the names of the selected items, 
either as a function result or a set of special variables 
(584). 

Again, as described elsewhere, the actual WAIT is 
performed through the use of the P-code interrupt func- 
tion. In this case the INTER-ROLLOUT routine waits 
for the user to select from the selection, and returns the 
input to the program variables through the POST- 
WAIT routine. . 

FIG. 31 is a routine which demonstrates how the 
interpreter program permits a user to perform digital 
signatures. As indicated at block 600, the data to be 
digitally signed is assembled based on data which the 
program is able to access: this includes user supplied 
input, data read from files, data accumulated from pre- 
vious traversals, data based on the user's environment 
(e.g., the user's TSO identifier), the time, data incorpo- 
rated into the program itself, and data derived from 



10 



IS 



built-in functions (such as the built-in X12 data dictio- 20 classes of functions: 



(630). Thereafter, data is read from the specified file and 
saved as program variables 632. FIG. 35 illustrates how 
the travelling program may update or create a file from 
program variables. As indicated in block 640, the user 
file into which data is to be written is first determined. 
Thereafter, a function is invoked that writes program 
variables into the user file 642. 

It should be understood, even if not explicitly de- 
scribed in every case, that any program function which 
could lead to data loss, alteration, damage or disclosure 
is subject to security controls. Such controls can be 
applied at the program level, and either be tied to the 
incoming program and possibly by combined in some 
predetermined fashion with those also imposed by the 
user. 

Therefore, for example, in the above case, the travel- 
ling program could only read or write user's data files if 
the program were so authorized. 
Security constraints exist for at least the following 



nary). Appropriate information is displayed to the user 
(602). The user then decides whether or she wishes to 
sign the data, as indicated at block 604. If the user indi- 
cates he wishes to perform the signature, the system 
invokes the sign function, as illustrated in FIG. 26, to 25 
further interact with the user and complete the signa- 
ture (606). Thereafter, the digital signature is generated 
and saved as a program variable 608. 

FIG. 31 and the flowcharts which follow depict, in 
part, how a user might utilize the travelling program 30 
methodology described therein, while performing rela- 
tively few operations to accomplish powerful functions 
built into the aforedescribed interpreter. 

FIG. 32 exemplifies how a user would verify re- 
ceived information. As indicated in block 610, the data 35 
which is expected to be verified are assembled Thereaf- 
ter, a "verify* function with the assembled data and the 
saved digital signature, together with any possible au- 
thority requirements is invoked. The verification func- 
tion may be accomplished as described in U.S. Pat No. 40 
5,005,200 or using standard digital signature techniques 
if a conventional digital signature operation was utilized 
to sign the variables. Thereafter, a determination is 
made based on the processing in block circuit 12 as to 
whether the signature is verified (614). If so, then the 45 
program execution continues. If not, an error condition 
results indicating that the data has been tampered with 
or that there has been some kind of programming error 
616. Return codes are defined to allow the pr o giam to 



Display data to the user. 
Soliciting input from the user. 
Performing digital signatures. 
Reading data from user files. 
Creating user files. 
Erasing user files. 
Writing data into user files. 
Remaining user files. 
Attaching user files. 
Exporting attached files into user files. 
Invoking an digital notary device. 
Receiving mcoming electronic mail 
Reading the contents of electronic mail 
Moving or archiving mcoming mail 
Deleting mcoming mail. 

Generating outbound electronic mail, or doing vari- 
ous types of data transmissions 
Being coupled to various types of equipment, device, 
and services (FAX, printers, office equipment, 
robot 'devices^manufacturing equipment, etc.) 
Performing a program traversal. 
Invoking external programs. 
Accessing, updating, activating, erasing, altering, 

invoking, or attaching other travelling programs 
FIG. 36 is illustrates how a travelling program may 
be designed to be split and sent to a number of different 
recipients and FIG. 37 demonstrates how the previ- 
ously split programs may be merged. 
Turning first to FIG. 36, the travelling program may 



distinguish whether the signature was invalid, whether 50 need to be split in order, for example, to acquire survey 



it supported authorization capability, and if so, whether 
the authorization was confirmed. 

FIG. 33 illustrates how a travelling program collects 
a file to be transferred Initially, the program determines 
the file to be transferred byrfor example^ displaying to 55 
the user, a list of files 620. A check may be made to 
determine whether it is necessary to have user interac- 
tion in order to determine the file (622). If yes, then the 
user is prompted to determine the file to be transferred 



data from a number of different recipients or to collect 
or distribute data to a number of different executives in 
an organization. Initially, the travelling program per- 
forms various housekeeping operations to prepare ..to,, 
split 650! TTTiefeafulJ/vanabies are set in accordance 
with particular application requirements, eg., the sur- 
vey run by a particular user 652. Destination users are 
then determined and the traverse function is invoked as 
per FIGS. 20 and 21 to transmit the image of the pro- 



624. If it is not necessary to have user interaction to 60 grams, the programs variables together with any other 



determine the file, then the entire file contents are at- 
tached to the set of data to be transferred 626. The 
operation is accomplished using the attached functions 
set forth in FIG. 22 which involves building a file con- 
trol block as previously described. 

FIG. 34 illustrates the travelling program operations 
performed in reading data from a specified file. Initially 
the file is determined containing the data to be read 



appropriate data tailored to the individual recipients 
654. The transmitted variables may change from in- 
stance 1 (656) to instance 2 (658), instance 3 (660), to 
instance N (662). 
65 A check is ultimately made to determine whether 
there are more destinations to which to transmit (664). 
If so, then the routine branches back to 652 to transmit 
to the further destination. If there are no further destina- 
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tions, then the .final transfer is performed 666 in the then written to a special file 71Z A check is ™»H* to 
same manner as explained above with respect to 654 to determine whether all other instances have arrived as 
result in the final "instance" 668, thereafter resulting in indicated at 714. If so, then the collected data is pro- 
the completion of the splitting operation. cessed 716, and the program traverses to the next desti- 

In other examples, it may also be that the master 5 nation 718 and the routine is exited If all other instances 
program simply goes into some other processing. Per- have not arrived as determined at 714, then a message is 
haps, if it were running in a batch environment as an displayed such as "waiting for more forms to arrive" 
input distributor, and all the input were presently ex- (720) and the current instance is HpI^pH 722, and the 
hausted (having just been spun off to a number of users), routine is exited. 

it would go into a delay until something else arrived. 10 FIG. 39 is a flowchart indicating how the travelling 

Turning to the FIG. 37 merge operation, the travel- program has been designed to accommodate electronic 
ling program has the intelligence to transfer itself from data interchange (EDI) generation functions. FIG. 39 
user to user to merge further data until the merging more specifically demonstrates how a particular "X12" 
operation is complete. Initially, the travelling pi o giam standard characteristic may be used. The X12 standard 
arrives at a merging destination and is executed (680). A 15 has an associated data dictionary and segment dictio- 
check is made to determine whether this is a master nary. The X12 segment dictionary, for example, may be 
'instance" which is determined by a predetermined used to define all segments necessary to define a pur- 
variable being set If it is determined that this is not a chase order. Each segment is defined as being a piece of 
master instance at 682, a slave instance is identified 684. data which is then looked up in a dictionary. Because 
At (685) the slave program checks if it has been invoked 20 there are many different ways to specify the quantity of 
with the special "DEBRIEF" parameter (which is sim- an item, many variations of data are permitted in X12. 
ply a convention used by this program to determine The present system embeds the X12 data dictionary 
when the slave is being called by the master), and if so into the interpreter which may be called as a built-in 
(687) passes back all pertinent information to the master function. As indicated in block 7201, initially a call is 
instance, then exits. If this is not the DEBRIEF invoca- 25 made to the X12 subroutine by specifying a segment 
tkm, then a check is made to determine whether the nam** and items "XX, YY, WW, . . . " The program can 
master instance is available, Le., has already arrived, provide X12 data code for popular common options 
686. If the master instance is available then a call is typical in the organization's environment, so as to build 
made to the master instance 696, through the use of the a short list of options in order of normal usage. Exam- 
call shown in FIG. 18. After the master instance has 30 pies of such items are, in a purchase order context, item 
been invoked, the routine branches back to block 680. If number, part number and quantity. This call will result 
the master is not available, a message is issued that the in a call to the built in data dictionary, 
master control for the series has not arrived 688. A check is made to determine whether the short list is 

Presuming the master instance has arrived and has empty (as indicated in 724). If so, the segment name is 
been invoked, then at block 682 a determination is made 35 used to call , the built-in function X12SEGUST that 
that this is the master instance and a check will be made locates the segment dictionary table of all associated 
to determine whether any other slave instances have data options 736. Thereafter, X 1 2DATAN AME built- 
arrived 692. If so, then the slave instance will be in- in function would be used to expand the data dictionary 
voked with a predetermined parameter to initiate the each associated description data 738 and the long com- 
collection of data (referred to perhaps as "debriefing") 40 plete list would be displayed 740. 
694. At entry point E, data is collected from the in- If the check at 724 indicates that there is a short list, 
stance and is returned to the master and is written to a the X 1 2D AT AN AME data dictionary is used to locate 
collection file 706. Thereafter, the instance that has just the expanded description of each of the options on the 
been invoked is erased 708 and the routine branches short list Thereafter, the short list is displayed 728. 
back to 692 in which case further information is col- 45 Then a check is m«to to determine whether the user 
lected if other instances have arrived. wants the full long list as indicated at 730. If the answer 

If no further instances have arrived the file is checked is yes, then block 736 is CTer^itH as described above. If 
to see if all instances have all arrived (698). If they have, no, then the user's selection from either the short list or 
as determined at 700, then the data could be read from the long list is accepted (732). 
the collection into variables in the travelling program. 50 A check is then made at block 734 to determine 
Depending on the expected size of the collection file, whether all data is collected. If so, we assemble and 
and the nature of the processing, it might be more desir- emit the completed X12 transaction 742 and t hen exit 
able for the master program to process the completed the routine. With respect to the emitting operation re- 
file at that moment and either traverse itself to the next ferred,to in conjunction with 742,. the present invention 
destination, oY" to encapsulate the result "into a simple 55 contemplates the capability of mailing specific sets of 
message, perhaps even an EDI transaction and simply X12 data in addition to mailing the entire travelling 
transmit that raw data. program. If all data is not collected as indicated by the 

In other cases it might be appropriate for the program check in 734, then more data items are retrieved and the 
to ATTACH the file to itself and transfer it wholesale routine execution is repeated. 

to another process. The file is erased and aggregate data 60 FIG. 40 relates to the use of the travelling program in 
is transmitted to the next destination 704. If all instances receiving an electronic data interchange, transaction, 
have not yet arrived, then a message is issued such as For example, a particular user may have received a 
"waiting for forms to arrive*' (702) and the routine is travelling program generated purchase order. Initially, 
temporarily existed. the received EDI transaction is read 750. Perhaps by a 

FIG. 38 shows an alternative approach to merging 65 timer-delay travelling program, as described with FIG. 
previously split travelling program information. As 29, which spawns copies of itself as input arrives. The 
shown in block 710, the travelling program arrives at a encoded EDI is then parsed into program variables 752. 
merging destination and is run. The collected data is The received EDI is then moved to an archive reposi- 
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tory to preserve that which has been received for possi- 
ble audit The segments are then processed via a cou- 
pled segment dictionary 756. The segment rules associ- 
ated with X12 are enforced which, for example, may 
relate to not having certain kinds of data in particular 
fields, 758. For each data item, the data dictionary asso- 
ciated with each segment is located 760. For a statement 
such as shown in 762 where DESC=X- 
12DATANAME (SEGCODE, DATA ITEM), this 
statement will result in a call to the data dictionary to 
get a meaningful description of the data item. The re- 
trieved meaningful description will be placed into a 
display variable resulting in, for example, a display of 
the purchase order in a purchase order format All data 
items are processed by branching back to block 762 and 
all segments are processed branching back to 756. 

The preferred embodiment also allows access to a 
Digital Notary facility by providing built-in functions 
which can access a digital notary, or notary device such 
as described in inventor's U.S. Pat No. 5,001,752 
(which is incorporated herein by reference), or other 
devices as welL 

By allowing a travelling program to access such a 
facility, the travelling program is able to move data to a 
platform where the digital notary can be easily ac- 
cessed, then using the built-in function to do so. This 
allows notarization for important signatures, times- 
tamps for inbound traffic or for. any other reason. Since 
such notarization is strictly under control of the pro- 
gram, any criteria whatever, whether automatic or 
based on user requests, can be used. 

Also as described earlier, the facility allows for the 
coupling to outbound FAX so that electronic forms, in 
addition to being converted to EDI, or printed, can also 35 
be faxed to the ultimate recipient 

Also, as implied, but not explicitly stated, even when 
a travelling program emits an EDI transaction, it may 
still be activated later. One example would be a travel- 
ring program which first serves as an electronic requisi- 40 
tkm then, after sufficient approving signatures, gener- 
ates a purchase order. It could then send itself to a 
repository where it could later be reactivated when the 
corresponding invoice and bills eventually arrive (elec- 
tronic or otherwise) and can serve as a method for 45 
reconciling the order with the shipment received and 
the billing. It can incorporate logic which to keep track 
of which items have been received, and which are still 
pending. Because of the ability to flexibly direct itself, it 
can span many different sites. Insofar as handling ship- 50 
ping and receiving, it is also possible to couple the trav- 
elling program with a bar code reader and validate 
materials sent and received without human data entry. 

The preferred embodiment envisions that the travel- 
"ling program could ' be ' coupled ' to a variety of equip- 55 
ment, including office equipment, and other devices and 
facilitates. 

Also, any given traversal could also be sent simulta- 
neously to a variety of recipients. 

The following listing reiterates and summarizes many 60 
of the above-described functions (and identifies some 
additional functions) which the preferred embodiment 
is capable of performing. This list is only illustrative and 
is not intended to be exhaustive of the many other appli- 
cations to which the present invention may be advanta- 
geously applied. 

Displaying data to the user using a layout language 
(similar to, eg., TxX, or SCRIPT), Soliciting input 
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from the user using a layout-type language (similar 
to, e.g., TeX, or SCRIPT). 

Performing digital signatures for data computed 
under program control. 

Verifying digital signatures based on data computer 
under program control 

Handling co-signatures, possibly including routing 
suggestions derived from the signer's certificates. 

Reading data from user files, 

Creating user files, 

Erasing user files 

Writing data into user files 

Renaming user files 

Receiving incoming electronic mail 

Reading the contents of electronic mail 

Moving or archiving incoming mail 

Deleting incoming mail 

Generating outbound electronic Tnail 

Coupling to and controlling an outbound FAX server 

Coupling to and controlling a printer. 

Generating a graphical image- 
Coupling to and controlling a device that can receive 
and t ransmi t audio signals 

Accessing various types of equipment, including of- 
fice equipment, computer equipment (tapes, disks, 
eta) robot devices, rnanufactnring equipment, etc. 

Splitting an instance of the travelling program into 
several instances by virtue of multiple traversals. 

Being able to re-combine the data contained in the 
several travelling programs, possibly not even re- 
flecting the same program, into a single form. 

Erasing other instances of travelling programs. 

Invoking external programs. 

Invoking other travelling programs as subroutines. 

Activating other travelling programs as indepen- 
dently executing functions. 

Extracting data from a dormant (non-executing) trav- 
elling program. 

Detenxumng information about another (non-execut- 
ing) travelling program without have to execute 
it— such as name of the program, and other status, 
etc. 

Extracting information from the certificates associ- 
ated with digital signatures. This information being 
used to help direct routing if cosignature require- 
ments are involved. 

Making a copy of a travelling program as a data 
variable within another program, or ATTACHing 
a travelling program as a file to another. 

Using one travelling program (the "carrier*') to trans- 
port a new version of another to various destina- 
tions, and replacing the program segment of exist- 
ing instances with another, more up-to-date version 
of the program. One ..vjay, to do. this wonld be : for- ; 
the newer program segment to be added to tine end 
of existing travelling programs. Enhancements to 
the existing interpreter/loader would recognize 
that a program segment following the closure seg- 
ment reflected a suggested program revision. After 
whatever normal transmission was performed, it 
would then validate the digital signatures associ- 
ated with the proposed revised program, and, if 
they carried the proper authority, would then com- 
mence using the new program in place of the pro- 
gram which had arrived as part of the standard 
traversal. 

Attaching user files. 

Exporting attached files into user files. 
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Detaching previously attached files. 

Accessing a digital notary device . 

Performing a program traversal 

Transmitting user data (in other than a traversal), so 
that the transmission does not include the travel- 
ling program itself (e.g., simply sending a message 
to another destination. 

Using built-in functions to simplify the use, creation, 
display, construction and receipt of EDI (such as 
X12 or EDEFACT) to conveniently supply com- 
mon information and facilities without having to 
supply these functions in the travelling program. 
This includes built-in functions which access the 
Data Element Dictionary, the Segment Dictio- 
nary, the segment rules, and the transaction sets 
themselves. 

While the invention has been described in connection 
with what is presently considered to be the most practi- 
cal embodiment, it is to be understood that the invention ^ 
is not to be limited to the disclosed embodiment, but on 
the contrary, is intended to cover various modifications 
and equivalent arrangements included within the spirit 
and scope of the appended claims. 

What is claimed is: 

L In a communications system having a plurality of 
digital computers coupled to a channel over which 
computers exchange digital messages, a method for 
processing information among said computers compris- 
ing the steps of: 

executing on a digital computer a first travelling pro- 
gram comprising a sequence of digital instructions 
which determines at least one next destination that 
receives the set of instructions, said set of instruc- 
tions including instructions for transmitting said 35 
instructions together with accompanying digital 
data to said next destination; 
transmitting to at least one of said digital computers a 

second travelling program; and 
executing the second travelling program under direc- 40 
tion of the first travelling program. 

2. A method according to claim 1, wherein the first 
and second travelling programs include the same set of 
instructions but do not include the same set of p io gtam 
variables. 

3. A method according to claim 1 wherein the first 
and second travelling programs comprise distinct sets of 
instructions. 

4. A method according to claim 1, further including 
the step of presenting data by the first travelling pro- 
gram to the second travelling program which defines 
the operation to be performed by the second travelling 
program. 

L . . 5. A method according to:claim 1 wherein the second 7 ^ 
travelling program returns data to the first travelling 
program. 

6. A method according to claim 1, wherein both 
travelling programs are transmitted in an interpretative 
format, whereby the travelling programs and data can 
be interpreted on a variety of computer system and 
hardware architectures. 

7. A method according to claim 6, whereby the inter- . 
pretative format can be processed on at least two dis- 
tinct types of computers. 

8. A method according to claim 1, further including 
the step of erasing the second travelling program from 
memory by the first travelling program. 
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9. A method according to claim 1, further including 
the step of preserving the second travelling program 
after its execution. 

10. In a communications system having a plurality of 
digital computers coupled to a channel over which 
digital computers exchange messages, a method for 
processing information among said computers compris- 
ing the steps of: 

executing on a digital computer a first travelling pro- 
gram instance comprising a sequence of digital 
instructions, including instructions which deter- 
mine at least one next destination that receives the 
set of instructions, said set of instructions including 
instructions for transmitting said instructions to- 
. gether with accompanying digital data to said next 
destination; 

transmitting to at least one of said digital computers a 
second travelling program instance; and' ~ 

processing the second travelling program under di- 
rection of instructions in the first travelling pro- 
gram instance. 

11. A method according to claim 10 wherein the 
processing operation includes the step of erasing the 
second travelling program instance. 

12. A method according to claim 10, wherein the 
processing step includes the step of extracting data from 
the second travelling program instance. 

13. A method according to claim 10, wherein the 
processing step includes the step of altering the pro- 
gram instructions in the second travelling program 
instance. 

14. A method according to claim 10 wherein the 
processing operation includes the step of altering the 
value of the variables stored in the second travelling 
program instance. 

15. A method according to claim 10 wherein said 
second program instance includes the same instructions 
as the first program instance. 

16. In a communications system having a plurality of 
digital computers coupled to a channel • over - which 
digital computers exchange messages, a method for 
processing digital information among said computers 
comprising the steps of: 

executing on a first computer with a sequence of 
digital instructions, including instructions which 
determine at least one next destination that should 
receive the set of instructions, said set of instruc- 
tions including instructions for transmitting said 
instructions together with accompanying digital 
data to said next destination; 

selecting a file in response to execution of said se- 
quence of instructions; and 

transmitting at least part of the content of said se- 
lected file to said next destination in. resr^nse^to^jvj^ 
* execution of said sequence of instructions. " 

17. A method according to claim 16, including the 
step of digitally signing at least part of the data of said 
file. 

18. A method according to claim 16, including the 
step of computing a hash value of at least part of the 
data of said file. 

19. In a communications system having a plurality 
digital of computers coupled to a channel over which 
digital computers exchange messages, a method for 
forwarding information in said communications system 
comprising the steps of: 

executing on a first digital computer a set of instruc- 
tions including digital instructions which generate 
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a plurality.of instances of said set of instructions 
and which initiate transmission to at least a first and 
a second destination which respectively receive 
one of said instances together with accompanying 
digital data; 

including within said instances transmitted to said 
first and second destinations digital instructions for 
subsequently merging, at a merging, destination, 
data that has been accumulated during their dis- 
tinct transmission paths via said first and second 
destinations; and 

transmitting one of said instances to said first destina- 
tion and one of said instances to said second desti- 
nation. 

20. A method according to claim 19, farther includ- 
ing the steps of: 

establishing one instance, as the master instance; and 
controlling the master to extract data from other 
instances as they arrive at the merging destination. 20 

21. In a communications system having a plurality of 
digital computers coupled to a channel over which 
digital computers exchange messages, a method for 
processing digital information among said computers 
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comprising the steps of: 



instructions together with accompanying digital 

data to said next destination; 
transmitting said sequence of instructions to at least 

one next destination; and 
performing a date/time notarization of information 

controlled by said sequence of instructions. 

25. In a communications system having a plurality of 
digital computers coupled to a channel over which 
digital computers exchange messages, a method for 
processing digital information among said computers 
comprising the steps of. 

executing on a first computer with a sequence of 
digital program instructions, including digital in- 
structions which determine at least one next desti- 
nation that receives the set of instructions, said set 
of instructions including instructions for transmit- 
ting said instructions together with accompanying 
digital data to said next destination; 

transmitting said sequence of digital instructions to at 
least one next destination; and 

performing a time delay operation under the control 
of said sequence of instructions. 

26. In a communications system having a plurality of 
digital computers coupled to a channel over which 



executing on a first computer with a sequence of 
digital program instructions, including instructions 
which determine at least one next destination that 
receive the set of instructions, said set of instruc- 
tions including instructions for tr ansmitting said 30 
instructions together with accompanying digital 
data to said next destination; 
qualifying the set of operations which said sequence 

of instructions is allowed to perform; 
transmitting said set of instructions to said next desti- 
nation; and 

detennining at said next destination whether an oper- 
ation to be performed under the control of said set 
of instructions is authorized. 

22. A method according to claim 21, wherein said 
step of qualifying the set of operations is specified by a 
party using said program. 

23. A method according to claim 21, further includ- 
ing the step of digitally signing information indicative of 45 
qualified operations by a party trusted by the parties 
using said travelling program. 

24. In a communications system having a plurality of 
digital computers coupled to a channel over which 
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processing digital information among said computers 
comprising the steps of: 
executing on a first digital computer a sequence of 
digital instructions, including digital instructions 
which determine at least one next destination that 
receives the sequence of digital instructions; 
acquiring digital data from a user of at least one of 
said computers under the control of said sequence 
of digital instructions; 
translating said data under the control of said se- 
quence of digital instructions into a predefined data 
structure; 

digitally signing at least part of said data structure via 
the execution of said sequence of digital instruc- 
tions to create a digital signature value; 'and 

transmitting digital information including said digital 
signature value to a next destination under the 
control of said sequence of digital instructions. 

27. A method according to claim 26, wherein said 
translating step includes the step of translating said data 
under control of said sequence of instructions into an 
Electronic Data Interchange (EDI) format 

28. A method according to claim 26, wherein at least 
part of the aggregate of said data structure together 



digital computers exchange messages, a method for 50 with the digital signature of said data structure is trans- 

processing digital information among said computers 

comprising the steps of: 
executing on a first digital computer a sequence of 
program instructions, including digital instructions 
wMch determinelit le^ cne nS^destin^cilhat 55 
receives the set of instructions, said set of instruc- 
tions including instructions for transmitting said 



mitted as a set of data independently of the sequence of 
digital instructions. 

29. A method according to claim 26, wherein the 
result of the digital signature feyera^jwhen^the ^set .of, 
instructions is executed at at least one subsequent desti- 
nation. 

* * * ♦ * 
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